beyondbinaryfandomcom-20200215-history
Hashmeshing
A hashmesh is a non-linear multi-partite information exchange mechanism based on the premise of a network of nodes running publically visible but internally secure encryption protocols. Verification is possible because any other node running the same encryption can validate or invalidate a transaction by proving the encrypted solution is valid. Nodes that do not run that encryption are incapable of validating the data directly, but can validate the encryption result by comparing the result generated by other nodes of the same network. Privacy is ensured because no one from other encryption networks are able to view raw data, but trust is guaranteed because of statistical probability, the odds that a 'bad player' in a network could: :1. lie about their encryption result :2. get a large percentage of their encryption pool to agree to lie about it :3. Randomly have ALL nodes selected by the validators happen to be nodes that had agreed to lie. In such a scheme, cross-chain transactions can be validated by miners who run different algorithms simply because they trust that the network has no incentive to lie about any individual transaction in such high levels of collusion. An extra incentive can be added that validators gain rewards proportional to their importance in the validation. e.g. the first validator could earn 50%, the second 30%, then the final 20% divided between the final N validators. This scheme incentivizes people to disagree with one another, because if the first validator is proven to have lied, then a new invalidation can be registered with the discoverer earning 50% of the reward (or more, if this incentive is wished to be increased). Hence, the security of the system is ensured by game theory assuming a large enough network of rational actors. Implementation A cross-chain ledger validation is complex because it's not simply trying to reach a consensus on the balances of all nodes on one network (which is how a blockchain avoids double-spending) - instead a cross-chain ledger needs to prevent double spends across multiple chains, which means that any currency being paid must be known to be a valid output of the paying node. Validation is possible because of two-way encryption protocols. Two-way encryption The paying node submits their most recent transaction history, a paying node will hold some form of ledger with the relevant chain or mesh for the currency they are using. Rather than validating the whole chain, it's merely enough to track the node's transaction far back enough to prove that there balance is at least high enough to pay the relevant amount. e.g. if a node with a ledger blaance of X tokens has recently been paid 30 tokens and since then has only spent 12, then their net balance is (X+18), and assuming that X>=0 then we can be sure that the node can afford any amount up to 18 tokens. In this way, a node's total transaction history is only relevant if they try to reduce their balance close to 0 tokens. The two-way encryption means that the entire ledger never has to be seen by someone receiving those tokens. Instead the paying node may submit an encrypted version of their transaction history, providing the encryption method they have used publically. The receiving node can learn this encryption method, but it is itself an encrypted file, hence only nodes with some 'stake' in that encryption in terms of having learned it will be able to view the transactions under that encryption. Encryptions can evolve over time to keep this barrier of entry high. Instead, the receiving node is only able to gain confidence by asking other nodes who run the same encryption code to independently verify that the encrypted data actually described a valid transaction history upon which to make that payment. The receiving node can verify that these nodes are using the same encryption because the encrypted files will be identical when they are decrypted. Of course, the receiving node never sees the decrypted files, but can independently verify that they have produced the same verification as the node themselves provided. This is statistically-verified cross-chain validation. Hash Mechanics Divergence Meshing * All nodes agree on an initial node state ('the genesis block') dkps * Each subsequent chain is defined by a series of divergences of 'difference hashes' * The hash of block 0 is a known commodity amongst all nodes and serves as the most basic level of chain-authentication * The public chain of any subsequent hash-network is then stored as a series of hashes of a local difference function * The private transactions that define each subsequent block is private * The 'difference matrix' which turns "block_N-1" into "block_N" (the set of transactions defining the Nth block) is never publically stored * Instead, the difference matrix is passed through a Hash Function to provide a 'difference hash' which encodes the information to produce each block of the 'private ledger' from the block before it * This series of hashes encodes entire ledgers in reduced storage space while also providing provably secure authentication (when designed appropriately) Quantum Hash Mechanics Developing hash functions intuitively using emergent contexts is possible with a powerful Quantum Computer (particularly Organic Quantum Computers). In this mode, the hash function is not fixed, but a continuous stream of linearly-encoded information (like a ledger in a blockchain) is stored in a sequence of non-deterministically encoded "hashes" (these are not necessarily "hashes" in a digital sense, but can be any form of asymmetrically-encoded information) Polyhashing Dual Hashing An appropriately unreplicable hash function is secure because it ensures that data can be kept private, while being publically authenticated in the form of a compressed, unpredictable Hash Function Hash(data) - whose solutions cannot be brute force engineered to replicate its output. However, this only works by balancing the complexity of the hash function against the perceived maximum computing power of an enemy hacker's network. If you create a one-in-a-trillion hash algorithm, then the odds of reverse-engineering two distinct meaningful messages out of the same known (public) hash output. Hence, data can be asymmetrically-authenticated via the presumed certainty that the odds of reverse-engineering a meaningful hash are so low that the logical conclusion upon viewing meaningful data with the correct hash is that the data is authentic. Allowing your private data's hash to be stored in the form of TWO distinct hashes (e.g. by using two complementary hash functions) allows a public record of any of your private transactions to be proven under necessity, while remaining anonymous otherwise. We not only make the problem of reverse-engineering both hashes to give the same meaningful data as an input, but they are now time-synchronized in that both solutions had to be known at the same moment in time in order for them to exist in the public dual-chain ledger. In such a case, it is possible to guarantee that the solution time of the problem on at least one of the reverse-engineering steps is necessarily near-zero in computing time in order to solve both simultaenously after viewing the result on the public ledger. The important step is to allow some private-bleedthrough, in which the true transactions have a continuing impact on some other parts of the network, to ensure that fraudulent nodes of the ledger do not attempt to 'rewrite history'. 'True History' is formed probabilistically in a Quantum Hash Network with nodes in different regions experiencing different states and some divergent forks in their respective chains since 'block 0'. Nodes belonging to incompatible ledgers can avoid one another and form semi-separate networks. Network allegiances can be traced through public identifiers such as node ID's (still anonymous to the actual user). Nodes can choose to limit network allegiance to only other members of the allegiance who also support one another rather than profiting off other economies. Temporally-Asymmetric Encrpytion Encryption using minimal data, e.g. storing an entire image as a single character in a large alphabet (e.g. a single unicode character) :Use the time property of the data as a means of encoding information. * A % sent at a global UTC time 10:12am means something different to the same % at 10:13am : Decrypt the messages off-chain, meaning that different side-chains can assign different meaning to each block, but all blocks will agree on the symbol and time With multi-symbol messages, the chain agrees on the time properties of each symbol, even if several share the same time, all side-chains can verify these core characteristics of the same chain. Non-Deterministic Hashmeshing. Notes Page 2038 Category:Blockchain Category:Cryptography Category:Quantum Cryptography Category:Organic Quantum Computing Category:Human Quantum Computing Category:Information Age Category:Age of Aquarius Category:2018 Ideas Category:Ideas Category:Hash Mechanics Category:Hashmeshing